Besides the inconvenient usage points discussed above, my main concern to open this PR is to discourage the type of mutable state that mixes concerns (a single ViewState class with many fields) from becoming a pattern in the codebase.

My worry is that if a different developer takes the single class ViewState and organically starts adding state to the class, it will eventually lead to a complex mix of incongruent or invalid states.

Let me illustrate my fears, suppose a dev adds to the original ViewState a couple more fields of data:

data class HomeViewState(
  val isLoading: Boolean = false,
  val showError: Boolean = false,
  val userEmailTitle: ViewStateString? = null,
  val favoriteItems: List<ItemType>? = null,
  val showLoginButton: Boolean = false
)

When the ViewModel gets an authentication error, it should set viewState.showLoginButton = true, the other fields should also be cleared but what about the userEmailTitle should it stay for next login or should it be cleared? That is a good question for a PO, but managing the state permutations becomes very complex.

The systemic problem here is that we are mixing, error + loading + content + authentication states into one single class and for every new field in this class we should create a matrix of combinations between all the fields to find all the illegal states and write defensive code to proactively prevent each on of those cases.

The bugs that come from not proactively preventing each illegal state combination can be very tricky to reproduce and debug.

Bug example from the existing code in main branch for fetchUser:

    fun fetchUser() {
        viewModelScope.launch {

            _uiState.update { it.copy(showError = false, isLoading = true) }

            handleAction(
                action = fetchUserUseCase(),
                onError = { _uiState.update { it.copy(showError = true, isLoading = false) } },
                onSuccess = { _uiState.update { it.copy(isLoading = false) } },
            )
        }
    }

If fetchUser is called twice, it's possible that both calls set the state to loading, then the first one fails setting showError = true, isLoading = false and the second one succeeds but the content is not shown because the error is still visible, this is the code on main for success (the developer forgot to remove the error on success😱):

  onSuccess = { _uiState.update { it.copy(isLoading = false) } },

Pfew, This is a hard one to have an opinion about. I tried this approach once and regretted it.

But you make some good points. Let's discuss them during a android coffee or dev meet. I'd like to know what the other devs think.

More input from an article explaining the gotchas of using both approaches and why sealed hierarchies are safer (including drawbacks and solutions)

https://proandroiddev.com/how-to-safely-update-state-in-your-kotlin-apps-bf51ccebe2ef

More input from an article explaining the gotchas of using both approaches and why sealed hierarchies are safer (including drawbacks and solutions)

https://proandroiddev.com/how-to-safely-update-state-in-your-kotlin-apps-bf51ccebe2ef

Great article!

Okay, agreed! You've found a bug 👍 , and the article found many more, so let's go for the less developer friendly, but better approach!

There are more possible bugs and improvements mentioned in the article, on state management, let's go fix these as well, in another PR?